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Abstract 


Software  product  line  (SPL)  and  service-oriented  architecture  (SOA)  approaches  both  enable  an 
organization  to  reuse  existing  assets  and  capabilities  rather  than  repeatedly  redeveloping  them  for 
new  systems.  Organizations  can  capitalize  on  such  reuse  in  software-reliant  systems  to  achieve 
business  goals  such  as  productivity  gains,  decreased  development  costs,  improved  time  to  market, 
increased  reliability,  increased  agility,  and  competitive  advantage.  Both  approaches  accommodate 
variation  in  the  software  that  is  being  reused  or  the  way  in  which  it  is  employed.  Meeting  busi¬ 
ness  goals  through  a  product  line  or  a  set  of  service-oriented  systems  requires  managing  the  varia¬ 
tion  of  assets,  including  services.  This  report  examines  combining  existing  SOA  and  software 
product  line  approaches  for  variation  management.  This  examination  has  two  objectives:  1)  for 
service-oriented  systems  development,  to  present  an  approach  for  managing  variation  by  identify¬ 
ing  and  designing  services  explicitly  targeted  to  multiple  service-oriented  systems,  2)  for  SPL 
systems,  to  present  an  approach  for  managing  variation  where  services  are  a  mechanism  for  varia¬ 
tion  within  a  product  line  or  for  expanding  the  product  line  scope. 
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1  Introduction 


Software  product  line  (SPL)  and  service-oriented  architecture  (SOA)  approaches  to  software  de¬ 
velopment  share  a  common  goal.  They  both  enable  an  organization  to  reuse  existing  assets  and 
capabilities  rather  than  repeatedly  redeveloping  them  for  new  systems.  By  adopting  these  ap¬ 
proaches,  organizations  can  capitalize  on  reuse  in  software-reliant  systems  to  achieve  business 
goals  such  as  productivity  gains,  decreased  development  costs,  improved  time  to  market,  greater 
agility,  higher  reliability,  and  competitive  advantage  [Cohen  2008]. 

We  define  systems  that  are  built  using  these  approaches  as  follows: 

An  SPL  is  a  set  of  software-intensive  systems  that  share  a  common,  managed  set  of  features* 1 
that  satisfy  the  specific  needs  of  a  particular  market  segment  or  mission  and  that  are  developed 
from  a  common  set  of  core  assets  in  a  prescribed  way  [Clements  200 1  ] . 

-SOA  is  a  way  of  designing  systems  composed  of  services  that  are  invoked  in  a  standard  way” 
[Lewis  2008b].  It  is  an  architectural  style  or  design  paradigm  that  guides  the  composition  and 
orchestration  of  services  to  implement  business  processes. 

This  report  highlights  the  mutual  benefits  of  combining  systematic  reuse  approaches  from  product 
line  development  with  flexible  approaches  for  implementing  business  processes  in  an  SOA.  Un¬ 
der  a  combined  SOA-SPL  approach,  developers  build  core  assets,  including  services,  and  con¬ 
struct  systems  through  the  systematic  reuse  of  these  core  assets  in  a  predefined  way.  Product  line 
approaches  exploit  the  commonality  across  the  products  applying  planned  variation  among  their 
core  assets.  SOA  provides  a  flexible  mechanism  for  dealing  with  variation  through  services  that 
are  not  bound  to  a  specific  product.  In  addition,  a  product  line  may  be  composed  of  service- 
oriented  systems,  if  services  are  a  basic  element  of  composition  and  provide  support  for  variation 
among  members  of  the  product  family.  Developers  of  service-oriented  systems  can  apply  product 
line  approaches  to  extract  service  core  assets  from  legacy  systems  and  develop  the  architecture  for 
new  systems  within  the  enterprise. 

This  report  satisfies  two  objectives  in  examining  the  combining  of  existing  SOA  and  SPL  ap¬ 
proaches: 

1 .  for  service-oriented  systems  development,  to  present  an  approach  for  managing  variation  to 
identify  and  design  services  targeted  to  multiple  service-oriented  systems 

2.  for  SPL  systems,  to  present  an  approach  for  managing  variation  where  services  are  a  me¬ 
chanism  for  variation  within  a  product  line  or  for  expanding  the  product  line  scope 

The  need  for  variation  may  be  driven  by  market  conditions,  market  opportunities,  new  technolo¬ 
gies,  and  other  business-related  factors.  This  need  may  be  stated  in  the  form  of  business  goals  set 
by  organizations  that  develop  SPL  or  service-oriented  systems.  While  goals  are  similar  in  both 
types  of  development  organizations,  they  lead  to  different  variation  needs.  For  example,  in  ser¬ 
vice-oriented  systems,  the  need  generally  includes  reuse  of  a  service  across  enterprise  systems. 


A  feature  is  a  prominent  or  distinctive  user-visible  aspect,  quality,  or  characteristic  of  a  software  system  or  sys¬ 
tems  [Kang  1990], 
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For  SPL  systems,  the  need  includes  systematic  reuse  across  a  product  line.  At  the  same  time,  both 
types  of  systems  must  meet  quality  attributes  that  may  vary  across  the  breadth  of  SPL  or  service- 
oriented  systems. 

The  next  section  of  this  report  defines  the  contexts  for  variation  management:  SPL  and  service- 
oriented  systems.  Section  3  describes  how  SPL  and  SOA  approaches  can  be  combined  for  reuse. 
Section  4  discusses  variation  management  in  an  SPL  through  use  of  services  and  the  application 
of  product  line  approaches  to  support  SOA  design  decisions.  Section  5  examines  future  work  in 
this  area. 
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2  The  Basics  of  Software  Product  Lines  and  Service- 
Oriented  Architectures 


2.1  Software  Product  Lines 

Software  product  line  practice  is  the  systematic  use  of  core  assets  to  assemble,  instantiate,  or  gen¬ 
erate  the  multiple  products  that  constitute  a  software  product  line  [Northrop  2009].  An  organiza¬ 
tion’s  success  in  building  a  software  product  line  lies  in  the  ability  of  the  organization  to  identify  a 
group  of  like  systems,  the  common  and  variant  features  of  the  systems,  the  assets  used  to  develop 
the  systems  in  the  product  line,  and  a  plan  for  building  the  systems. 

Product  line  scope  and  product  line  analysis  define  the  boundaries  and  requirements  of  the  soft¬ 
ware  product  line,  based  on  the  business  goals  of  the  organization  [Chastek  2001].  The  scope 
identifies  the  characteristics  of  the  defined  systems  as  being  inside  or  outside  the  boundaries  of 
the  software  product  line.  The  scope  also  helps  identify  the  common  aspects  of  the  systems,  as 
well  as  expected  ways  in  which  they  may  vary. 

Product  line  analysis  applies  established  modeling  techniques  to  engineer  the  common  and  vary¬ 
ing  requirements  for  a  product  line,  based  on  input  from  stakeholders.  Feature  modeling  within 
product  line  analysis  captures  the  functional  and  nonfunctional  requirements  of  the  products  in  the 
product  line  and  the  decisions  about  common  and  variant  capabilities  and  behaviors  across  the 
product  line  [Chastek  2001]. 

Composition  elements  of  product  line  products  are  the  product  line  core  assets — artifacts  or  re¬ 
sources  used  in  the  production  of  products  in  an  SPL.  A  core  asset  may  be  the  architecture,  a 
software  component,  a  process  model,  a  plan,  a  document,  or  any  other  artifact  useful  in  building 
a  system.  Each  core  asset  has  an  attached  process  that  describes  how  the  core  asset  is  used  in 
product  production,  including  variant  information.  For  example,  the  product  line  architecture  must 
include  mechanisms  to  support  the  explicitly  allowed  variations  in  the  products  within  the  product 
line  scope;  the  attached  process  defines  how  that  variation  mechanism  is  used  to  generate  the  ar¬ 
chitecture  for  a  specific  product  variant. 

A  production  plan  prescribes  how  the  products  are  produced  from  the  core  assets  and  incorporates 
their  attached  processes,  ft  includes  the  process  to  be  used  for  building  products  (the  production 
process )  and  the  overall  implementation  approach  (the  production  method )  [Northrop  2009].  The 
production  process  is  influenced  by  such  contextual  factors  as  product  constraints 2  and  produc¬ 
tion  constraints* * 3  and  the  production  strategy.4 


Product  constraints  are  common  and  variant  features  and  behavioral  attributes  associated  with  the  products  in 
the  product  line  scope. 

Production  constraints  are  any  restriction  on  the  timing,  development  environment,  processes,  or  developer 
skills  associated  with  the  creation  of  products  in  a  product  line. 

The  production  strategy  is  the  overall  approach  for  realizing  both  the  core  assets  and  the  products.  It  specifies 
the  “prescribed  manner”  of  development  called  for  in  the  definition  of  a  software  product  line. 
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2.2  Service-Oriented  Architecture 

A  service-oriented  architecture  (SO A)  provides  a  way  to  design,  develop,  deploy,  and  man¬ 
age  systems  characterized  by  coarse-grained  services  that  represent  reusable  business  func¬ 
tionality  and  service  consumers  that  compose  applications  or  systems  using  the  functionality 
provided  by  these  services  through  standard  interfaces  [Lewis  2008a] . 

Two  important  principles  of  an  SOA  are  the  identification  of  services  aligned  with  business  driv¬ 
ers  and  the  ability  to  address  multiple  execution  environments  by  separating  the  service  descrip¬ 
tion  (i.e.,  interface)  from  its  implementation.  Systems  that  employ  an  SOA  architectural  style  are 
called  service-oriented  systems. 

The  major  elements  of  service-oriented  systems  are  services,  service  consumers,  and  an  SOA  in¬ 
frastructure.  The  basic  compositional  elements  of  a  service-oriented  system  are  services — units  of 
work  that  are  applied  to  implement  a  business  process  to  achieve  a  desired  end  result  for  a  service 
consumer.  They  are  self-contained,  reusable  components,  configured  to  separate  the  standardized, 
well-defined  service  interfaces  from  the  service’s  implementation.  Service  providers  expose  the 
capabilities  of  the  service  through  the  interface.  Services  are  usually  coarse-grained  business  func¬ 
tionality  (such  as  customer  lookup)  rather  than  fine-grained  functionality  (such  as  customer  ad¬ 
dress  lookup).  They  can  be  globally  distributed  across  organizations  and  reconfigured  to  support 
new  business  processes.  A  service  registry  is  usually  employed  to  enable  service  consumers  to 
discover  available  services  [Lewis  2008a], 

Service  consumers  are  clients  for  the  functionality  provided  by  the  services.  They  query  the  regi¬ 
stry  for  services  with  desired  characteristics  and  compose  or  orchestrate  applications  using  a  ser¬ 
vice  or  composition  of  services.  Some  examples  of  service  consumers  are  end-user  applications, 
portals,  intra-organizational  enterprise  systems  and  systems  external  to  the  organization,  or  even 
other  services  in  the  context  of  composite  services  [Lewis  2008a]. 

The  SOA  infrastructure  is  what  connects  service  consumers  to  services.  It  usually  implements  a 
loosely  coupled,  synchronous  or  asynchronous,  message-based  communication  model.  The  infra¬ 
structure  often  contains  elements  to  support  service  discovery,  security,  data  transformation,  and 
other  operations.  One  common  SOA  infrastructure  is  an  enterprise  service  bus  (ESB)  to  support 
SOA  environments  [Lewis  2008a]. 
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3  Combining  SPL  and  SOA  Approaches 


Meeting  business  goals  through  a  product  line  or  a  set  of  service-oriented  systems  requires  varia¬ 
tion  management  of  assets,  including  services.  Variation  management  — emprises  all  activities  to 
explicitly  model,  manage,  and  document  those  parts,  which  vary  among  the  products  of  a  product 
line”  [John  2009].  Variation  management  applies  to  services  in  both  the  service-oriented  and 
product  line  contexts.  In  both  types  of  systems,  variation  points  may  be  implemented  either  in  a 
single  service  (where  a  service  interface  may  offer  parameterization  or  some  other  variation  me¬ 
chanism)  or  through  similar  services  to  address  variation.  To  support  variation  mechanisms,  SOA 
defines  the  infrastructure  that  selects  and  invokes  the  appropriate  service  and  service  variation  for 
use  in  a  specific  system. 

Examining  the  SOA  and  SPL  approaches  more  closely — starting  with  the  definitions  provided  in 
Sections  1  and  2 — can  help  organizations  identify  and  exploit  the  characteristics  of  each  approach 
and  combine  them  successfully  for  variation  management.  Those  definitions  deal  with  aspects  of 
scope,  the  design  approach,  the  source  of  variation,  the  application  target,  composition  elements, 
and  the  technical  approach.  These  aspects  were  the  focus  of  discussion  at  the  2008  Workshop  on 
Service-Oriented  Architectures  and  Software  Product  Lines  [SOAPL  2008],  The  two  definitions 
are  decomposed  in  Table  1. 


Table  1:  Contrasting  Aspects  of  SOA  and  Product  Line  Definitions 


Aspects 

Definition  of  an  SOA 

Definition  of  an  SPL 

Scope 

* 

A  set  of  software-intensive  systems 

Design  approach 

A  way  of  designing  systems 

** 

Source  of  variation 

* 

that  share  a  common,  managed  set  of 
features 

Application  target 

to  implement  business  processes 

satisfying  the  specific  needs  of  a 
particular  market  segment  or  mission 

Compositional  elements 

composed  of  services 

and  that  are  developed  from  a  com¬ 
mon  set  of  core  assets 

Technical  approach 

invoked  in  a  standard  way 

in  a  prescribed  way 

*  not  explicit  in  the  definition 

**  not  explicit  in  the  definition  but  captured  in  the  technical  approach 


SOA  and  SPLs  address  most  of  these  aspects,  and  both  define  design  approaches.  SOA  defines 
the  composition  and  orchestration  of  services  as  an  explicit  design  approach.  An  SPL  defines  the 
design  approach  in  terms  of  the  software  architecture  for  that  product  line.  SPLs  also  define  a 
comprehensive  set  of  core  assets,  including  but  not  limited  to  a  product  line  architecture,  compo¬ 
nents,  test  cases,  and  so  forth.  In  terms  of  targets,  software  product  lines  address  a  market  segment 
or  mission,  while  an  SOA  is  intended  to  implement  business  processes  within  an  enterprise.  Final¬ 
ly,  SOA  prescribes  a  standard  for  service  invocation,  and  software  product  lines  require  a  pre¬ 
scribed  way  for  constructing  each  product  in  the  product  line.* * 5 


These  differences  are  highlighted  only  to  contrast  the  different  emphasis  within  each  definition.  They  are  not 

meant  to  imply  anything  about  the  superiority  of  one  over  the  other. 
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Further,  significant  distinctions  between  service-oriented  and  product  line  approaches  emerge 
because  of  how  scope  and  variation  are  utilized.  A  product  line  is  built  within  an  initial  scope  that 
usually  evolves  over  time  within  a  market  segment  due  to  technological  or  market  changes  and 
business  decisions.  Organizations  may  also  identify  ways  in  which  to  apply  part  or  all  of  a  core 
asset  base  to  products  in  a  new  market.  In  an  SOA  approach,  services  are  applied  to  address  inte¬ 
gration  across  systems  in  the  enterprise  and  to  capitalize  on  legacy  investment  [Butler  2006].  In 
an  SOA  approach,  the  scope  grows  or  contracts  to  address  user  needs,  and  scoping,  as  practiced  in 
software  product  lines,  is  generally  not  done. 

While  variation  and  variation  management  are  key  to  an  SPL  approach,  they  are  not  highlights  of 
an  SOA  approach.  Y et,  an  SOA  approach  can  be  employed  as  a  variation  mechanism  when  core 
assets  and  products  are  developed  in  a  product  line.  In  an  SPL  approach,  developers  of  software 
core  assets  would  package  desired  capability  as  a  service.  That  service  may  have  built-in  variation 
points  that  are  accessible  through  parameterized  service  calls,  or  the  service  registry  may  identify 
variations  among  related  service  components  that  may  include  both  the  newly  packaged  capabili¬ 
ties  and  existing  services  from  the  enterprise.  The  SOA  infrastructure  provides  an  invocation  me¬ 
chanism  to  the  needed  service  core  asset  for  product  development.  Variation  management  in  this 
context  allows  the  tailored  use  of  services  to  provide  the  exact,  desired  capability  for  a  specific 
product.  The  dynamic  nature  of  service  invocation  may  support  adaptation  and  more  dynamic 
growth  of  a  product  line’s  scope.  SOA  may  also  support  a  more  opportunistic  response  to  chang¬ 
ing  market  conditions  with  product  line  adaptation  or  new  product  lines. 

For  service-oriented  systems,  product  line  approaches  could  expand  on  the  migration  of  legacy 
software  to  services,  if  multiple  applications  were  seen  as  the  targets  for  the  newly  exposed  ser¬ 
vices.  Variation  management  in  this  context  helps  identify  the  need  for  variation  in  services  across 
a  range  of  potential  service-oriented  systems.  Similarly,  the  service  registry  could  support  the  dis¬ 
covery  of  alternative  services  that  may  address  variations  among  the  applications  that  require 
those  services.  For  service  consumers,  variation  management  helps  identify  a  specific  service  that 
addresses  an  end-user  need.  This  latter  approach  supports  software  product  lines  as  well  and  pro¬ 
vides  software  core  assets  with  variation  points  for  a  specific  product  line  product. 


6  |  CMU/SEI-201 0-TN-007 


4  Variation  Management  for  Services  Under  an  SPL 
Approach 


This  section  discusses  variation  management  for  services  when  an  SPL  approach  is  used  and  how 
the  approach  can  be  used  to  support  SOA  design  decisions.  An  SPL  approach  can  help  organiza¬ 
tions 

•  achieve  specific  SOA  business  goals — such  as  increased  reuse  and  market  responsiveness — 
through  variation  management  of  services.  For  example,  developers  of  a  comprehensive 
product  line  of  medical  information  management  systems  can  design  a  common  patient  au¬ 
thentication  service  with  built-in  variation  points  to  support  the  management  of  healthcare, 
delivery  of  insurance  coverage,  retrieval  of  needed  records,  or  scheduling  of  appointments. 

•  employ  SOA  service  invocation  as  a  variation  mechanism.  For  example,  the  product  line  for  a 
medical  information  management  system  may  have  different  offerings  for  different  users, 
such  as  hospitals,  specialized  clinics,  medical  offices,  and  individuals.  The  authentication  ser¬ 
vice  invocation  protocol  will  support  the  variation  needed  for  each  type  of  offering  to  make 
the  appropriate  information  available  when  requested  and  restrict  unauthorized  access. 

To  integrate  SPL  and  SOA  approaches,  product  line  development  organizations  must  apply  varia¬ 
tion  management  within  SOA  approaches,  and  service-oriented  system  developers  must  apply  the 
approaches  that  product  line  developers  use.  This  integration  must  provide  variation  management 
of  services  (e.g.,  variation  points  generated  by  the  needs  of  different  types  of  users  of  the  medical 
information  management  system  mentioned  above)  and  must  address  services  as  a  variation  me¬ 
chanism  (e.g.,  the  service  invocation  protocol  that  selects  from  among  those  variations). 

The  next  four  sections  describe  four  principles  of  variation  management  in  product  line  or  ser¬ 
vice-oriented  systems.  To  illustrate  these  principles,  we  use  the  example  of  health  information 
exchange  (HIE)  systems.  Bartholdt  offers  a  meaningful  example  of  SOA  concepts  in  a  product 
line  context  applied  to  HIE  systems  [Bartholdt  2008].  These  systems  provide  distributed  man¬ 
agement  of  patient-related  data  for  hospital  chains,  regions,  or  even  whole  nations.  The  case  study 
illustrates  the  integration  of  SOA-based  HIE  implementations  within  a  product  line  based  on 
known  product  variation.  Figure  1  [RTI  2007]  illustrates  some  of  the  services  obtained  by  the  in¬ 
stitutions  supported  by  an  HIE.  Though  not  depicted  here,  an  HIE  may  also  obtain  services  from 
external  sources. 
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Figure  1:  Product  Line  Capabilities  in  a  Health  Information  Exchange 

The  four  principles  are  listed  below.  Each  principle  is  accompanied  by  an  HIE  system  capability 

that  can  result  from  applying  the  principle. 

1 .  Recognize  the  commonality  and  variants  across  the  scope  of  a  product  line  or  across  some 
group  of  service-oriented  systems  within  the  enterprise.  Product  variation  to  support  com¬ 
partmentalized  access  to  patient  data  depending  on  the  user 

2.  Leverage  the  recognized  commonality  by  building  core  assets,  including  services,  across  the 
variants  with  established  points  of  variation.  Core  asset  variation  to  support  different  health 
systems,  clinics,  hospitals,  and  labs 

3.  Address  the  enterprise  integration  needs  that  service-oriented  systems  must  offer.  Integration 
with  external  services 

4.  Address  end-user  needs  for  variation  within  service-oriented  systems.  User  variation  to  ac¬ 
commodate  unique  work  flow  or  user  interface  needs 

Section  5.1  discusses  a  final  principle: 

5.  Establish  production  plans  that  use  appropriate  variation  mechanisms  to  build  product  line  or 
service-oriented  systems  based  on  these  principles. 

along  with  other  future  work  for  merging  SPL  and  SOA  practices. 
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Each  of  the  following  sections  will  also  include  a  discussion  of  methods  from  the  SOA-PL  litera¬ 
ture  as  they  apply  to  one  of  the  above  four  principles.  The  literature  discussion  will  highlight  po¬ 
tential  contributions  or  areas  for  further  investigation  of  methods  to  support  the  SOA-PL  connec¬ 
tion.  The  section  will  also  discuss  shortcomings  in  the  SOA  methods  when  applied  directly  to 
product  line  development.  The  HIE  product  line  will  illustrate  how  SOA  methods  can  be  en¬ 
hanced  to  address  product  line  needs  in  each  of  the  four  areas. 

4.1  Recognize  Commonality  and  Variants 

Product  line  scoping  identifies  which  potential  products  are  in  or  out  of  the  product  line.  Scoping 
supports  this  decision  process  by  identifying  what  is  common  or  varying  among  products  in  the 
product  line.  Product  line  members  will  share  common  features,  while  unique  or  alternative  fea¬ 
tures  documented  in  the  product  line  scope  will  be  a  determinant  in  including  or  excluding  a  po¬ 
tential  member.  An  understanding  of  commonality  and  bounding  variation  lets  an  organization 
detennine  whether  a  product  can  be  built  within  the  product  line.  The  level  of  variation  manage¬ 
ment  across  the  product  line  is  captured  in  the  definition  as  a  — cormon,  managed  set  of  features” 
and  is  essential  to  product  line  systems. 

Methods  that  address  reuse  for  service-oriented  systems  generally  do  not  consider  product  varia¬ 
tion  among  systems  that  will  use  or  reuse  those  services.  Developing  service-oriented  systems 
traditionally  involves  identifying  services  for  a  specified  target  but  not  defining  a  scope  for  a  set 
of  SOA -based  systems  implemented  with  those  services.  Some  methods  seek  to  identify  services 
that  legacy  systems  can  expose,  but  with  a  specific  application  target  for  the  service.  The  Carnegie 
Mellon®  Software  Engineering  Institute  developed  such  a  method — the  Service  Migration  and 
Reuse  Technique  (SMART)  [Lewis  2008b].  SMART  refers  to  the  service  identification  as 
reuse — reuse  of  a  legacy  component  or  capability  in  the  form  of  a  service  [Lewis  2008b],  New 
applications  may  also  become  a  target  for  the  service,  and  that  would  also  be  reuse.  However, 
SMART  does  not  address  the  need  for  a  service  (with  some  degree  of  variation)  across  a  range  of 
applications  or  a  method  for  building  in  variation  to  accommodate  multiple  system  targets. 

Other  methods  also  lack  consideration  of  scope  for  application  of  a  set  of  services.  Balaji  de¬ 
scribes  — arvices  in  an  SOA  ...  as  reusable  assets.”  Service  assets  in  Balaji’s  method  help  leve¬ 
rage  previous  investments  and  may  influence  future  investment  with  all  the  benefits  of  systematic 
reuse.  Service  assets  support  the  quick  construction  of  — aw  [business  support]  processes  as  a 
choreographed  set  of  existing  services”  [Balaji  2007a].  The  method  includes  the  following 
among  its  listed  SOA  assets:  business  process  models,  reference  architectures,  and  design  pat¬ 
terns.  However,  Balaji’s  method  does  not  define  an  initial  scope  for  applying  a  service. 

In  applying  product  line  techniques  to  SOA,  users  of  the  Component  Based  Development  and 
Integration  (CBDI)  method  look  at  both  a  suite  of  applications  (CBDI  concept  of  enterprise)  and 
an  application  family  (CBDI  concept  of  product  line)  [Butler  2006].  Either  may  be  the  focus  of 
the  reuse  of  service  assets.  However,  the  CBDI  method  cautions  users  against  trying  to  analyze 
how  all  the  systems  interact  in  a  suite  and  doesn’t  address  reuse  across  the  family.  Engineering 
services  for  systematic  reuse  would  require  this  analysis  as  part  of  the  scoping  process. 


Carnegie  Mellon  is  registered  in  the  U.S.  Patent  and  Trademark  Office  by  Carnegie  Mellon  University. 
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The  HIE  product  line  spans  classes  of  customers  across  a  diverse  market.  The  product  line  must 
also  accommodate  data  exchange  standards.  In  Bartholdt’s  study,  understanding  product  variation 
and  scoping  for  HIE  systems  required  the 

•  addressing  of  customer  specifics  or  integration  with  existing  third  parties 

•  ability  to  quickly  deploy  a  partial  system  or  deploy  an  existing  system  to  new  platforms 

•  extensibility  to  address  the  emerging  national  data  exchange  standard 

The  scoping  of  product  variation  led  to  some  specific  variation  points  realized  in  service  assets. 
The  application  of  an  SOA  approach  for  the  product  line  supported  exposing  master  patient  index 
(MPI)  services  to  find  duplicate  patient  data  (Bartholdt  2008).  However,  this  service  is  optional 
within  the  product  line;  some  systems  in  the  product  line  may  use  outside  implementations  for  this 
service.  In  another  example,  workflow  engine  approaches  within  the  product  line  applied  chains 
of  services  to  accomplish  site-specific  business  processes. 

As  part  of  engineering  services  from  legacy  components  or  capability,  the  service  migration  can 
include  a  scoping  process  to  identify  existing  or  potential  applications  that  could  use  the  service. 

If  these  applications  require  slight  variations  in  the  service,  the  target  scoping  process  can  use 
product  line  approaches  to 

•  identify  service  features  that  are  common  among  the  targets 

•  engineer  variations  or  variant  services  to  accommodate  the  target-unique  features 

For  example,  the  patient  authentication  service  must  permit  the  retrieval  of  electronic  data  records 
for  authorized  users  of  a  set  of  applications  but  will  differ  in  terms  of  the  kinds  of  information — 
diagnosis,  billing,  and  prescribed  treatments — that  may  be  delivered  for  each  class  of  user.  The 
service  may  also  vary  by  the  types  of  identification  data  that  must  be  entered  to  permit  access — 
identification  numbers,  personal  identifying  questions,  or  biometrics.  Engineering  a  common  ser¬ 
vice  could  include  provisions  for  these  variations  or  offer  multiple  services  to  accommodate  the 
needed  variation. 

4.2  Leverage  Recognized  Commonality 

Product  line  scope  identifies  the  need  for  variation  across  products.  Software  product  line  devel¬ 
opers  achieve  variation  across  products  by  applying  core  assets  with  built-in  variation  points.  To 
detennine  the  coverage  of  assets  within  and  across  products,  core  asset  development  applies  what 
has  been  tenned  reuse  scope,  that  is,  — 'toich  features  [within  product  line  scope]  are  to  be  devel¬ 
oped  for  reuse,  which  for  individual  products  without  reuse”  [Schmid  2005].  The  intent  of  the 
reuse  scope  is  similar  to  that  of  service  migration  from  legacy  within  SMART — identifying  which 
legacy  capabilities  should  be  exposed  for  reuse.  The  identified  features  may  be  implemented  as 
requirements,  within  the  architecture,  or  in  other  software-related  core  assets.  Similarly,  variations 
within  features  must  be  addressed  within  the  appropriate  core  assets:  requirements,  architecture, 
components,  test  cases,  or  non-software  core  assets  such  as  a  configuration  management  plan. 

Capturing  variation  is  the  responsibility  of  a  core  asset  developer  [Bachmann  2005],  In  this  con¬ 
text,  the  developer  may  be  performing  a  requirements,  architecture,  testing,  or  technical  manage¬ 
ment  activity,  depending  on  the  core  asset.  Variation  in  the  use  of  a  core  asset  may  be  addressed 
by  variation  points,  spelling  out  different  uses  of  a  core  asset  that  include  options  and  alternatives. 
Two  other  factors  involved  in  the  use  of  variation  are  variation  mechanisms  and  the  core  asset 
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attached  process.  A  variation  mechanism  defines  the  implementation  approach  that  supports  the 
application  of  a  specific  variation.  For  an  architecture-level  variation,  a  mechanism  might  include 
object-oriented  extension  through  adding  new  attribute/method  features.  For  a  non-software  core 
asset  such  as  a  document,  an  XML  file  may  be  interpreted  to  select  alternative  text  paragraphs, 
graphics,  or  styling.  The  attached  process  gives  the  core  asset  user  explicit  guidance  in  using  the 
core  asset  and  its  variation  points  and  mechanisms. 

The  SOA  approach  may  contribute  to  product  line  variation  by  supporting  services  as  software 
core  assets.  In  linking  product  line  and  service  variation,  a  layered  approach  to  service  implemen¬ 
tation  demonstrates  variation  management  within  an  SOA  [Ludwig  2007].  This  approach  identi¬ 
fies  customizable  services  at  an  atomic  layer  (e.g.,  purchasing  service,  human  resources  service). 
Service  fulfillment  (i.e.,  implementation)  permits  customization  through  the  specifics  of  a  request 
to  an  atomic  service.  The  specific  request  — enahsis  variability  management  by  allowing  the  defini¬ 
tion  of  variants  of  steps  in  the  service  fulfillment  flow  as  alternative  implementation  flows.”  The 
layered  service  infrastructure  provides  the  variation  mechanisms  for  selection  among  service  op¬ 
tions  and  alternatives.  For  example,  the  service  flow  of  a  routine  purchase  request  does  not  invoke 
the  approval  or  multiple  bid  steps  of  a  major  purchase. 

Other  methods  capture  the  goal  of  identifying  variations  within  services  for  use  across  related  sys¬ 
tems  or,  potentially,  in  unforeseen  ways.  Feature  analysis  has  been  applied  to  service-oriented 
reengineering  [Chen  2005]  to  support  identifying  services  as  core  assets  for  application  beyond 
the  single  target.  Applying  asset-based  development  approaches  to  services  is  also  a  focus  of  Ba- 
laji’s  work  emphasizing  tooling,  life  cycle,  and  governance  [Balaji  2007a].  These  three  elements 
are  also  part  of  managing  variability  through  the  service  registry  [Balaji  2007b].6  The  use  of  an 
SOA  for  multiple  applications  may  help  identify  variations  that  will  lead  to  a  change  in  product 
line  scope  or  that  can  respond  to  new  or  changing  market  conditions.  Using  services  to  manage 
variability  may  lead  to  dynamic  product  line  scope — where  scope  easily  adapts  to  changing 
needs — or  to  the  identification  of  totally  new  product  lines  based  on  parts  of  an  existing  core  asset 
base. 

The  HIE  system  provides  examples  of  both  core  asset  variation  and  the  use  of  service  invocation 
as  a  variation  mechanism.  Service  design  can  incorporate  variation  points  [Bartholdt  2008].  Var¬ 
iations  among  in-scope  HIE  applications  may  lead  to  alternate  service  implementations,  differen¬ 
tiations  in  workflows,  or  variability  in  customer  environments  (e.g.,  hospitals,  clinics,  or  labs).  To 
reduce  the  costs  of  managing  multiple  variation  points,  this  approach  has  developed  pre¬ 
configurations  as  a  variation  mechanism.  The  pre-configurations  link  workflow  services  or  tasks 
for  a  particular  class  of  user  or  situational  need  [Brandt  2003].  Use  of  pre-configurations  ad¬ 
dresses  testability  by  reducing  the  number  of  service  combinations. 


The  service  registry  identifies  web  services  available  for  discovery  and  invocation.  The  registry  supports  all 
variation  management  through  interface  descriptions  such  as  the  Web  Service  Description  Language  (WSDL) 
to  match  service  providers  to  service  users. 
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4.3  Address  Enterprise  Integration  Needs 

An  SOA  strategy  addresses  business  goals  such  as  the  following  that  support  enterprise  integra¬ 
tion  [Lewis  2008a]: 

•  Integrate  business  partners  (potentially  across  multiple  computing  platforms). 

•  Improve  internal  business  processes  through  accessing  legacy  systems. 

•  Increase  information  to  customers  through  customizable  portals  and  information  selection. 

These  goals  apply  across  boundaries  of  existing  product  lines  and  require  variations  in  product 
context  to  an  extent  not  addressed  in  the  traditional  product  line  scope.  In  addition,  the  enterprise 
requires  many  different  sets  of  systems,  potentially  product  lines  in  their  own  right.  Such  integra¬ 
tion  variation — a  context  in  which  product  line  members  must  operate  or  interoperate — is  outward 
focused.  Traditional  scope  is  more  inward  focused:  What  will  the  products  in  the  product  line  do? 
An  SOA  that  provides  integration  mechanisms  supports  the  sharing  of  services  across  divergent 
systems  in  a  context-independent  fashion  and  leads  again  to  dynamic  product  line  scope. 

How  can  product  line  and  SOA  concepts  be  applied  in  the  enterprise  context?  An  SOA  may  mi¬ 
grate  to  levels  of  increasing  scope  from  project  to  line  of  business  (LOB)  to  enterprise  and  beyond 
[Arsanjani  2005],  This  work  defines  a  Service  Integration  Maturity  Model  that  is  incremental  and 
addresses  key  business  goals  such  as  quicker  time  to  production,  lower  costs,  and  competitive 
differentiation.  Initial  states  in  service  integration  are  ad  hoc,  with  little  reuse  across  service- 
oriented  systems.  As  this  service  integration  technology  is  adopted,  an  SOA  may  move  through 
increasing  levels  of  maturity.  The  first  level  is  project  focused,  moving  to  LOB  or  product  line 
focused,  with  a  few  common  services.  Still  more  common  services  depict  the  enterprise  level, 
while  value  net  adoption  is  characterized  by  common  services  and  customizations.  The  value  net 
level  may  achieve  — dnamically  reconfigurable  services,”  which  are  context-aware,  domain- 
specific  services  that  operate  by  forming  actively  executable  configurations  on  demand  [Arsanjani 
2006], 

In  the  HIE  enviromnent,  use  of  services  as  a  variation  mechanism  supports  enterprise  integration. 
The  varying  needs  across  HIE  systems  are  met  by  exchanging  implementations  with  different  va¬ 
riants  or  with  implementations  of  external  providers.  The  HIE  uses  this  approach  in  MPI  services 
to  identify  and  track  an  individual  patient  and  in  a  Document  Registry/Document  Repository. 
These  capabilities  may  be  implemented  using  internally  developed  or  externally  offered  services 
from  third  parties.  The  SOA  and  product  line  connection  has  reduced  integration  time  for  connect¬ 
ing  parts  of  the  system  to  each  other  and  to  external  systems. 

4.4  Address  End  User  Needs  for  Variation 

Organizations  building  either  product  line  or  service-oriented  systems  may  want  those  systems  to 
offer  end  users  the  ability  to  perform  their  own  customizations.  That  goal  may  be  achieved 
through  parameterization  as  a  variation  mechanism  in  product  lines  with  static  and  varying  parts 
under  end-user  control.  Cummins  engines  and  other  automotive  product  lines  apply  end-of-line 
programming  for  users,  such  as  engine  idle  speed  [Clements  2001]  or  limiters  for  engine  speed  or 
revolutions  per  minute.  Service-oriented  systems  often  include  customized  portal  interfaces  that 
allow  the  user  to  choose  the  services  and  use  them  to  make  customizations. 
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Intelligence  planning,  collection,  and  analysis  systems  illustrate  user  variation  within  an  SOA- 
based  implementation  of  a  product  line  [Jensen  2007].  Systems  in  the  product  line  use  a  core  asset 
base  of  services  (called  the  VIPER  Solution  Framework)  for  situational  awareness  based  on 
known  product  variation  across  the  product  scope.  A  single  application  may  define  user  roles  with 
individual  systems  tailored  to  specific  user  tasks.  Variation  mechanisms  for  this  customization 
include  both  component  selection  and  data  behavior  within  the  user  interface.  Individual  users 
may  perform  their  own  customizations.  Ease  in  training  can  be  a  business  goal  for  the  product 
line,  through  single-user  interfaces  for  tasks  involving  integrated  legacy  components.  For  exam¬ 
ple,  a  user  may  customize  one  property  editor  for  all  integrated  components  instead  of  a  different 
one  for  each  component.  This  same  property  editor  may  be  used  for  new  components  added  to  the 
system  in  the  future. 

In  Batholdt’s  study,  the  use  of  product  line  approaches  in  HIE  systems  helped  to  identify  features 
and  an  implementation  of  variability  at  the  end-user  level  [Bartholdt  2008].  The  focus  on  visible 
features  from  a  business  and  domain  perspective  linked  product  development  teams  and  the  cus¬ 
tomer.  Merging  product  line  and  SOA  approaches  supported  flexibility  in  a  dynamic  business 
environment,  enabling  users  to  define  unique  workflow  execution.  In  the  HIE  product  line,  each 
customer  has  a  specific  work  environment  and  unique  work  processes.  By  exposing  product  line 
functionality  as  services,  administrators  at  each  customer  site  can  perfonn  workflow-engine -based 
composition  of  services  using  a  variation  mechanism  to  accommodate  site-specific  requirements. 
To  support  end-user  variations,  product  line  and  SOA  approaches  have  merged  in  creating  core 
assets.  The  merged  approach  is  not  practiced  widely  within  product  lines,  however.  Service- 
oriented  systems  strive  to  achieve  end-user  variation  and  meet  customization  needs.  Core  asset 
development  practices  could  achieve  these  goals  by  addressing  variation  management  for  end- 
user  customization  as  part  of  a  product  line. 
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5 


Future  Work 


We  recommend  focusing  future  work  in  three  areas: 

1 .  establishing  production  plans  that  use  appropriate  variation  mechanisms  to  build  product  line 
or  service-oriented  systems.  (This  area  was  introduced  initially  in  Section  4  as  the  last  prin¬ 
ciple  for  successful  application  of  variation  management  in  services  and  their  variation  me¬ 
chanisms.) 

2.  looking  at  SOA  and  SPL  support  for  dynamic  execution  and  dynamic  variation  mechanisms 

3.  investigating  quality  attributes  as  they  relate  to  services  and  integrated  service-oriented, 
product  line  applications 

5.1  Establishing  Production  Plans  to  Encompass  SOA 

The  principles  discussed  in  Section  4  concentrate  on  product  variation.  A  second  category  of  vari¬ 
ation  is  related  to  the  production  of  products  in  a  product  line.  Such  variation  can  help  an  organi¬ 
zation  achieve  goals  for  improving  the  ability  to  produce  products,  such  as 

•  increased  market  share  while  maintaining  current  market  leadership  (i.e.,  standard  for  func¬ 
tion,  quality,  and  architecture) 

•  improved  product  marketability  through  improved  productivity  (lower  costs,  shorter  time  to 
market,  and  lower  maintenance  and  support  costs) 

•  ability  to  scale  down  for  low-cost  market  as  well  as  scale  up 

•  ability  to  quickly  deploy  a  partial  system  or  deploy  an  existing  system  to  new  platforms 

•  distribution  of  work  within  and  across  development  groups 

These  goals  address  production  rather  than  product  issues  [Chastek  2009]  and  affect  choices  in 
scope,  core  asset  development,  and  variation.  Achieving  quicker  time  to  market  may  dictate  the 
mining  of  service  assets  from  a  legacy  system,  thereby  achieving  variation  by  extracting  two  or 
more  similar  services.  Increasing  market  share  may  require  significant  variation  within  a  core  as¬ 
set  in  order  to  satisfy  the  many  needs  coming  from  the  marketplace.  A  production  strategy  ad¬ 
dresses  these  goals  (see  Section  2.1). 

Incorporating  an  SOA  approach  within  a  production  plan  will  affect  the  following: 

•  choices  about  service  extraction  and  variation 

•  enterprise  integration  across  systems  using  common  services 

•  end-user-defined  variation  selections 

SEI  SMART-SYS,  a  variation  of  SMART  [Lewis  2008b],  addresses  SOA-based  systems  devel¬ 
opment.  This  approach  provides  an  understanding  of  a  complete  service-oriented  system  in  the 
form  of  services,  consumers,  environment,  risks,  and  costs.  Currently  under  development, 
SMART-SYS  considers  many  of  the  same  issues  that  help  shape  the  production  strategy  and,  ul¬ 
timately,  the  production  plan.  Merging  SMART-SYS  with  product  line  production  planning  can 
help  incorporate  variation  management  with  an  SOA  approach.  This  connection  will  be  a  focus  of 
future  work. 
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5.2  Support  for  Dynamic  Service  Execution 

One  frequently  cited  distinction  between  the  SOA  and  product  line  approaches  is  the  advantage  of 
SOA  in  supporting  dynamic  execution  [Cohen  2008].  This  distinction  generally  focuses  on  dy¬ 
namic  service  execution,  while  component  execution  is  predefined.  However,  the  product  line 
architecture  may  also  support  a  dynamic  variation  mechanism  via  plug-ins  or  some  other  -plug 
and  play”  architecture. 

Another  way  to  link  dynamic  product  line  approaches  and  an  SOA  is  through  system  self¬ 
adaptation  [Dolog  2008].  Self-adaptation  supports  access  to  variant  information  resources  or  func¬ 
tions  as  provided  by  services.  Knowledge  about  the  needs  of  a  processing  step  provides  appropri¬ 
ate  information  for  service  selection  and  configuration.  These  needs  may  vary  based  on  the 

•  resource  and  information  access  environment 

•  application  domain 

•  user/context 

•  configuration — variants  and  their  meaningful  combinations  for  specific  purposes 

Service  providers  offer  many  services  that  vary  in  functionality  and  quality  attributes,  while  ser¬ 
vice  consumers  have  similar  requirements  and  need  to  achieve  value  through  composing  applica¬ 
tions  from  reusable  service  assets.  On  the  service  provider  side,  there  are  service  attributes  in  the 
form  of  features  to  describe  the  service.  A  variation  point  on  the  consumer  side  describes  user 
needs  via  features.  Under  this  approach,  a  matching  service  uses  a  feature  model  to  match  the  fea¬ 
tures  provided  by  a  service  to  those  needed  by  the  consumer. 

Future  work  in  this  area  would  need  to  consider,  among  other  concerns,  continuous  configuration 
management.  Dynamic  service  selection  may  deliver  different  services  for  the  same  service  re¬ 
quest,  depending  on  service  availability  or  other  conditions.  An  error  state  or  other  trace  must 
know  the  exact  configuration  that  resulted  from  the  specific  service  request.  The  use  of  a  feature 
model  as  a  dynamic  variation  mechanism  is  another  concern. 

5.3  Addressing  Quality  Attributes  Through  SOA  and  Product  Line  Approaches 

A  quality  attribute  is  a  property  of  a  work  product  or  goods  by  which  its  quality  will  be  judged  by 
some  stakeholder  or  stakeholders.  Quality  attribute  requirements  such  as  those  for  performance, 
security,  modifiability,  reliability,  and  usability  are  key  drivers  in  architecture  decisions,  including 
variation  management  [SEI  2009,  Bass  2003].  Future  work  in  this  area  will  look  at  an  actual  ser¬ 
vice-oriented  system  to  identify  the  appropriate  services  for  multiple  applications  as  targets.  These 
services  will  be  mined  for  shared  service  assets.  The  desired  quality  attributes  of  these  applica¬ 
tions  will  serve  as  drivers  for  design  choices  in  the  service-oriented  product  line  or  some  hybrid 
applications. 

The  Factory  pattern  describes  the  entire  software  product  line  organization.  The  pattern  includes 
steps  to  determine  the  scope  of  the  product  line,  the  production  capability  and  its  effective  use,  the 
parts  from  which  products  are  built,  and  the  process  to  monitor  the  operations  and  apply  course 
corrections  [Clements  2001],  This  pattern  could  be  applied  to  identify  the  scope  of  reuse  across  a 
potential  product  line  of  service-oriented  systems  and  develop  or  reengineer  existing  services  as 
software  core  assets.  The  effort  would  use  appropriate  architecture  techniques  to  design  the  archi¬ 
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tecture  for  the  product  line  and  identify  common  or  varying  quality  attributes  [Clements  2002, 
Bianco  2007].  SEI  Attribute-Driven  Design  [Bass  2003]  or  a  similar  technique  would  assure  con¬ 
formance  to  the  identified  quality  attributes  in  developing  services  as  core  assets,  and  an  architec¬ 
ture  evaluation  would  use  appropriate  quality  attributes  to  assess  the  fitness  of  the  architecture. 
The  production  capability  would  apply  services  and  other  core  assets  as  product  parts  for  building 
products  in  the  product  line.  Operations  monitoring  would  assure  the  successful  use  of  service 
mechanisms  to  achieve  desired  attributes  for  product  development. 
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6  Conclusions 


This  report  looks  at  combining  existing  SOA  and  SPL  approaches  for  variation  management. 

Both  approaches 

•  encourage  an  organization  to  reuse  existing  assets  and  capabilities  rather  than  repeatedly  re¬ 
develop  them  for  new  systems 

•  enable  organizations  to  capitalize  on  reuse  to  achieve  similar  business  goals  regarding  soft¬ 
ware-reliant  systems 

Meeting  business  goals  through  a  product  line  or  through  a  set  of  service-oriented  systems  re¬ 
quires  the  variation  of  assets,  including  services,  to  be  managed.  This  report  emphasizes  the  im¬ 
portance  of 

•  managing  variation  to  identify  and  design  services  targeted  to  multiple  service-oriented  sys¬ 
tems 

•  an  approach  for  managing  variation  where  services  became  a  mechanism  for  variation  within 
a  product  line  or  for  extending  product  line  scope 

This  report  describes  four  principles  leading  to  the  successful  application  of  variation  manage¬ 
ment  for  both  services  and  their  use  as  a  variation  mechanism: 

1 .  Recognize  the  commonality  and  variants  across  the  scope  of  a  product  line  or  across  some 
group  of  service-oriented  systems  within  the  enterprise. 

Following  this  principle  helps  organizations  identify  the  services  from  legacy  components  or 
capabilities  that  could  be  used  by  existing  or  potential  applications.  For  those  applications 
requiring  slight  variations  in  the  service,  the  scoping  process  could  employ  product  line  ap¬ 
proaches  to  identify  the  service  features  that  are  common  across  all  the  products.  Then,  the 
organization  could  engineer  variations  or  variant  services  to  accommodate  the  products’ 
unique  features. 

2.  Leverage  the  recognized  commonality  by  building  core  assets,  including  services,  across  the 
variants  with  established  points  of  variation. 

Following  this  principle  can  lead  organizations  to  address  variation  by  packaging  services  as 
core  assets  with  selected  features.  Service  invocation  can  be  used  as  a  product  line  variation 
mechanism.  An  SOA  approach  may  help  identify  variations  that  will  lead  to  a  change  in 
product  line  scope  or  that  can  respond  to  new  or  changing  market  conditions.  Using  services 
to  manage  variability  may  lead  to  dynamic  product  line  scope — where  scope  easily  adapts  to 
changing  needs — or  to  the  identification  of  new  product  lines  based  on  parts  of  an  existing 
core  asset  base. 

3.  Address  the  enterprise  integration  needs  that  service-oriented  systems  must  address  and  that 
can  be  applied  within  product  lines. 

Services  used  as  variation  mechanisms  support  enterprise  integration.  Varying  needs  across 
systems  are  met  by  implementations  with  different  variants  or  with  implementations  that  in¬ 
tegrate  with  external  services.  The  SOA  and  product  line  connection  has  caused  reduced  in¬ 
tegration  time  for  connecting  parts  of  the  system  to  each  other  and  to  external  systems.  In 
this  context,  enterprise  integration  could  encompass  many  different  sets  of  systems  and 
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product  lines,  enabling  SOA  integration  mechanisms  to  share  services  across  divergent  sys¬ 
tems  in  a  context-independent  fashion  and  lead  again  to  dynamic  product  line  scope. 

4.  Address  end-user  needs  for  variation  within  service-oriented  systems  that  can  be  applied 
within  product  lines. 

Product  line  approaches  can  identify  features  and  an  implementation  of  variability  at  the  end- 
user  level.  By  merging  product  line  and  SOA  approaches,  product  functionality  can  be  ex¬ 
posed  as  services,  enabling  the  workflow-based  composition  of  services  using  a  variation 
mechanism  to  accommodate  site-specific  requirements.  Merging  these  approaches  with  core 
asset  development  practices  could  elevate  variation  management  for  end-user  customization 
needs  in  a  product  line. 

Future  work  should  capture  promising  techniques  for  applying  these  results  to  service  identifica¬ 
tion  methods  such  as  SMART  and  to  variation  mechanisms  that  apply  an  SOA  within  a  product 
line.  A  future  workshop  may  be  built  around  such  techniques  and  bring  together  researchers  and 
practitioners  whose  work  has  been  documented  in  this  report. 
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present  an  approach  for  managing  variation  where  services  are  a  mechanism  for  variation  within  a  product  line  or  for  expanding  the 
product  line  scope. 
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